Note: Shared Folders are not available yet. It will be done as soon as Parallels Tools for boot2docker will be prepared.

awesome! we will need the shared folder support in order to provide the same experience as virtualbox / fusion. vmware uses their own build -- we could do the same for the interim until we get a long term solution.

Note: Shared Folders are not available yet. It will be done as soon as Parallels Tools for boot2docker will be prepared.

I know of at least three boot2docker images for the Parallels vagrant provider:

• blueimp/boot2docker
• Parallels/boot2docker-vagrant-box
• mitchellh/boot2docker-vagrant-box (not updated for a while; kernel doesn't appear to support installation of parallels tools)

It looks like the first two provide host file system access via NFS. I know that's non-standard, but it might provide a useful shortcut/workaround....

I think that currently it is best to wait and see if the boot2bocker gets
native psf-support. It that takes to long NFS is an option, or write an
open source psf driver.

But I think something will happen soon..
On Apr 14, 2015 5:09 AM, "Matt Bogosian (formerly @mbogosian)" <
[email protected]> wrote:

Note: Shared Folders are not available yet. It will be done as soon as
Parallels Tools for boot2docker will be prepared.

I know of at least three parallels providers for boot2docker images:

• blueimp/boot2docker http:///blueimp/boot2docker
• Parallels/boot2docker-vagrant-box
• mitchellh/boot2docker-vagrant-box
  http:///mitchellh/boot2docker-vagrant-box (not updated for a while)

It looks like at lease the blueimp version provides file system access via
NFS. I know that's non-standard, but it might provide a useful
shortcut/workaround....

—
Reply to this email directly or view it on GitHub
#939 (comment).

Housekeeping proposal: +label:proposed-driver?

Any thoughts/updates on this? Do we need 'offiical' boot2docker support for parallels tools, or is a custom boot2docker build viable?

@sean-brandt Parallels are working on Parallel Tools for boot2docker. May be, on the first stage it will be provided as a prebuilt custom boot2docker.iso

I will let you know here about any updates on this.

It's been a month - thoughts on just using the NFS option?

@sean-brandt If you want to run this with prl_fs support you can check out rickard-von-essen/boot2docker@9642433 to build a boot2docker.iso and build docker machine with this patch. If you do please supply some feedback if there is any problems.

This builds and starts, certainly, but it's unclear how to effectively use this with docker-machine at this point - and that's the ultimate goal, obviously.

@ehazlett We've finnaly released a custom boot2docker.iso based on v1.6.2 with Parallels Tools preinstalled:
https://github.com/Parallels/boot2docker/releases/tag/v1.6.2-prl-tools

I've rebased my pull-request and now parallels driver has the full functionality: there are shared folders available and integration tests are passed.

I'm going to send a pull-request to boot2docker with ParallelsTools support soon. I hope, it will be included to the one of the upcoming official release of boot2docker.iso and then I will send yet another PR here, switching parallels driver to the official ISO.

@legal90 🏆

@legal90 thanks!

@ehazlett Can it be merged to master?

@legal90 there is a process to go through (https://github.com/docker/machine/blob/master/CONTRIBUTING.md#drivers). We will most likely not get to this until after the 0.3.0 release.

Is there a special reason for requiring Parallels Desktop 11?
My build with requiring 10 works fine.

Where does it say it requires Parallels Desktop 11 ( which AFAIK is not released ) ?

On this line.
https://github.com/legal90/machine/blob/parallels-driver/drivers/parallels/parallels.go#L177

After compiling and trying it, the driver complained that it can only run with Parallels Desktop 11.
I changed the code to require only Parallels Desktop 10 and it worked fine.

I'm sorry, I should mention this earlier.
@suxor42 Parallels company gonna announce an official support of Boot2Docker guest OS and release a special "Parallels Tools for Boot2Docker" only in the scope of Parallels Desktop 11 release. It is in the closed Beta test now and will be published officially in Q3 2015.
So, internally we test Boot2Docker compatibility only with new PD 11 (boot2docker/boot2docker#954)

Also we have some other improvements in Parallels Desktop 11, which are useful for Docker Machine, but they are specific to PD 11. I'm gonna add some more commits here soon.

A you've noticed, Docker Machine could possibly work fine with Parallels Desktop 10 and of course we don't mind if somebody send an additional pull-request here to support it. But this use case could not be officially supported by Parallels company.

P.s. @ehazlett If you (or somebody else from Docker) would like to test this PR, Parallels can provide you an access to the pre-release version of Parallels Desktop 11. Just send me an e-mail (in the profile).

Wow, while I understand wanting to move to a plugin model, @legal90 has jumped through every hoop to get this PR merged. In addition, quite a few people have been waiting for the parallels support provided in this PR. It just isn't right to change the rules and deny the merge after he's worked for 4 months and fulfilled every request by the project maintainers.

@ehazlett
Upcoming plugin model in 0.5.* sounds cool and of course I will re-use the driver code there.
But I really disappointed by the decision to close this PR, because for last months I was trying to keep it available for merge and hoped that it could be released in 0.4.0 at least.

I guess it is not so difficult to test the driver (there are integration tests for it) and I'm ready to support it and keep it up-to-date, according to the latest changes in "master" branch.

I can understand your decision as a maintainer's (and I respect it), but we have to consider that in this case users of Parallels Desktop & Docker will not get this compatibility feature for yet another 1-2 months, so they should wait again. 😞

NOTE: The following thoughts and comments are exclusively my own. I have not sought input from @ehazlett, @legal90, or @rickard-von-essen before making them.

Various comments in this PR gave an impression that Parallels support would be merged. I don't think it's accurate to say, "we want to apologize for the lack of feedback on your pull request". It's not like this was submitted, and just sat here with zero official feedback (which would also be frustrating), but there has been continual interaction and guidance along the way, including on #436 (which this replaced). As far back as March, @ehazlett wrote:

... we are finishing the driver refactor in #756. after that we will start merging the pending drivers. thanks!

A few days later, @ehazlett wrote:

... i'm getting docs finished by next week. if one wanted to start on rebasing their drivers now that would be fine -- it would help get the docs in order.

Within eight days, @legal90 had rebased @rickard-von-essen's original PR and opened this PR four days after that. Shortly thereafter, @ehazlett requested:

... we will need the shared folder support in order to provide the same experience as virtualbox / fusion. vmware uses their own build -- we could do the same for the interim until we get a long term solution.

It took some time, but two months ago, Parallels officially released its own boot2docker image with the requisite packages to support shared folders, directly addressing @ehazlett's request.Then, @ehazlett asked for more, giving the impression that this would be eligible for inclusion back in 0.3.0:

@legal90 there is a process to go through (https://github.com/docker/machine/blob/master/CONTRIBUTING.md#drivers). We will most likely not get to this until after the 0.3.0 release.

That content could have been mentioned earlier, since it has existed in some form or another since last December (even before the merging of the VMWare Fusion driver). It lists five criteria:

• Address issues filed against this driver in a timely manner
• Review PRs for the driver
• Be responsible for maintaining the infrastructure to run unit tests and integration tests on the new supported environment
• Participate in a weekly driver maintainer meeting

And:

• ... make sure the driver adheres to the spec.

I haven't done an audit myself, but I'm assuming there weren't any issues complying with the specification. I think it's pretty clear Parallels in general (and @legal90 in particular) have demonstrated they comply with the first three. As for participating in a weekly maintainer meeting, I have no visibility, but I'm assuming this wouldn't be a problem?

As far as I can tell, the VMWare driver did not go through nearly this kind of scrutiny before being merged, and @rickard-von-essen's first attempt at Parallels driver was submitted just a few weeks after the VMWare driver was merged. (I'm not privy to all conversations, however.) I'm not suggesting anyone has been dragging feet, but it is frustrating when people like me have been eagerly awaiting a merge (@rickard-von-essen's original PR is from back in January). Since then, 0.2.0, 0.3.0, 0.3.1, and now 0.4.0rc1 have all sailed, leaving this on the dock. (Apologies for the pun.)

This is especially frustrating since VMWare has enjoyed support for quite a while. (As an aside, based on my casual testing on OS X, Parallels is superior to VMWare in several key resource usage respects, which is why I use it.) Here we have official and active support and expertise directly from the Parallels. @legal90 has been responsive and (as far as I can tell) delivered everything asked for.

I assume that with a plug-in architecture, the goal is to take Docker out of the gatekeeper/middleman role (which may avoid situations like this altogether). If this assumption is valid, then I'm all for the approach. And I want to make it clear that I'm not accusing @ehazlett (or anyone) of any malice. There are only so many hours in the day, and Docker has enjoyed a tremendous amount of attention from the community (which I understand translates into a lot of work for Docker folks). Still, it is clear that @legal90 (and @rickard-von-essen before him) have put in a lot of effort to get rebuffed (again) seemingly at the last minute.

It looks like ~12 driver requests were closed at the same time as this one. That's a lot of work for the team to manage to pull all of this together. Getting a driver interface in place so as to not be the point of contention is a great idea.

Many of those plugins are in a very rough state by comparison to the one in this issue, though. It seems like the work for Parallels integration is largely done to current standards, and it is not a niche plugin like raspberry pi or for an emerging cloud platform. It seems like this driver deserved serious consideration for 0.4.0, with the caveat that it will need to be a plugin once the plugin model is designed (sounds like this might require some time from the very preliminary notes in the plugin model announcement).

@legal90 would you consider releasing your own 0.4.0 binaries so that Parallels users can start working using this sooner, while the core project gets it's ducks lined up?

Edit: I also note that (according to IRC) ehazlett is on vacation this week.

@legal90 would you consider releasing your own 0.4.0 binaries so that Parallels users can start working using this sooner, while the core project gets it's ducks lined up?

👍 I think this is the right way to do until we get this into a new plugin system.

@legal90 I guess it is most credible if Parallels can host a patched binary.

@legal90 would you consider releasing your own 0.4.0 binaries so that Parallels users can start working using this sooner, while the core project gets it's ducks lined up?

@legal90 I guess it is most credible if Parallels can host a patched binary.

Yes, seem like we don't have another choice.
We'll publish our custom binaries when Docker Machine v0.4.0 and Parallels Desktop 11 for Mac will be released

@legal90 @rickard-von-essen I completely understand your frustration. However, we do not want to merge any more in at this time and I would strongly encourage and love to have you help us with #1626. It would be awesome to have a Parallels driver to show with the plugin launch.

This is very unfortunate. I've been following this ticket for months and have been using @legal90's driver for a while with absolutely no issues.

We'll publish our custom binaries when Docker Machine v0.4.0 and Parallels Desktop 11 for Mac will be released.

As a Parallels customer and user I can tell you that I won't be using any pre-built custom binaries (through no fault of your own!).

However Paralells decides to bundle their binaries it'll likely conflict with my current installation. I'm very skeptical that Parallels will be able to ship these binaries in a manner that does not conflict with everyone's installation of docker-machine and still make it easy to use, either through brew, manually compiled, or something else.

To be clear, I'm not placing blame on Parallels. I think they've done more than enough here. I just hope this doesn't turn into a deployment mess when PD11 comes out given the myriad of ways that docker-machine can be installed.

I completely understand your frustration. However, we do not want to merge any more in at this time and I would strongly encourage and love to have you help us with #1626. It would be awesome to have a Parallels driver to show with the plugin launch.

I understand that this decision probably did not come easy but I really wish you guys could have given a cut-off date for "old" drivers and/or created a migration plan. This whole thing just came too swiftly and left Parallels users with no options.

@legal90 would you consider releasing your own 0.4.0 binaries so that Parallels users can start working using this sooner, while the core project gets it's ducks lined up?

Agree. @legal90 - It would be extremely nice to have this, since docker-machine seems a bit awkward (requires Docker to be able to compile, which is a bit hard for me since I'm running it on OS X).

So, getting binaries with the code from this branch is a huge bonus. We can then hope that it can be properly integrated into docker-machine once #1626 is done.

Wholeheartedly agree with what has been said regarding considering this driver for inclusion on 0.4.0, especially since @legal90 has been nothing but cooperative with all the requirements stated by the maintainers. It's only fair that all the work put into this PR is not simply discarded.

Why not include this in 0.4.0 while working towards the new plugin architecture? @legal90 has already stated that he will support the migration whenever it needs to happen and like others have mentioned, the driver is already working very well for many of us.

We have released a custom version of docker-machine v0.4.0 with support of Parallels Desktop here:
https://github.com/Parallels/docker-machine/releases/tag/parallels%2F0.4.0
Repo: https://github.com/Parallels/docker-machine

Note: It works only with Parallels Desktop 11 for Mac Pro and Business editions. Standard edition doesn't have a full command line functionality and can not be used with Docker Machine.

Thanks for your work, @legal90.

It is however a little bit disappointing that the only way to use it is with buying into the subscription model of Parallels 11.

I've actually bought a license for Parallels 7, 8, 9 and 10 and would have bought a licence for 11 as well, but simply don't like the idea that the setup my development environment is based on will stop working if I don't continue my subscription.

@legal90 can you share exactly what's missing from the command line on the Standard edition?

@ruimarinho I can't provide the exact list right now, but I know that in Standard edition the command line interface is very limited.
It supports only some general actions like license manipulations, problem report sending, VM listing and something else.
It does not support VM creation, configuration, clone, start/stop/resume, and other important actions which are required by 3rd party tools like Docker Machine, Vagrant, Packer and so on.

Parallels has released "Pro" version of Parallels Desktop 11 especially for developers and engineers, so Standard edition is just for common cases with GUI only.

I have the Parallels Desktop 10 edition and I can start/stop/resume/suspend and all that from the prlctl command. I can also run commands in the vm, too..

On Aug 19, 2015, at 2:50 PM, Mikhail Zholobov [email protected] wrote:

@ruimarinho https://github.com/ruimarinho I can't provide the exact list right now, but I know that in Standard edition the command line interface is very limited now.
It supports only some general actions like license manipulations, problem report sending, VM listing and something else.
It does not support VM creation, configuration, clone, start/stop/resume, etc.

—
Reply to this email directly or view it on GitHub #939 (comment).

@jpapejr Yes, of course. I have to clarify that edition policy in my previous comment is related to Parallels Desktop 11 only. Previous version are not affected by this.

@legal90 thanks for clarifying that. Regarding NFS, is it possible to enable it for situations where shared folders are not appropriate? Specifically, I'm having some issues with LevelDB being able to access a mounted host volume on a container.

@ruimarinho I can add a new flag "--parallels-no-share", which means that Parallels Shared Folders won't be mounted in the machine, like it has been done recently for VirtualBox driver: #1622

But you will have to manage NFS export/mount by yourself. Is it OK for you?

Docker is the greatest thing happened in the last few years, and I really like it. We've been using it (docker engine) in production for almost a year, and looking forward to integrate other tools from docker eco-system (docker machine, and probably docker swarm).

But some decisions of the docker team like this one (not merging parallels driver in v0.4) just scary me. You, guys, should start taking the community feedback a little bit more serious.

+1 goes to Parallel's karma.
-10 to docker.

Plugin support is very real and is coming out in 0.5.0. The sheer amount of driver submissions, and those in core, was far too overwhelming for us to support on our own. When the 0.5.0 release happens (about 2-4 weeks from now), users will be able to use any driver that they want, including this one.

It just looks bad, when you add support for a huge amount of drivers to the core, and then reject to add support for another one.

On one hand I understand that the plugins are almost here and you want to use your resources efficiently. On other hand it means a delay of at least few months; you officially rejected the PR in August (2 months ago), and we still have to wait another month until plugin support is added. Given that the initial PR was created in April, it's more than 6 months. Taking into account that this project is just about a year old makes it look even worse.

In ideal world I would expect this PR to be merged for the current version, and move it to a plugin in 0.5.x when the plugin support is there.

+1 @korya

Yay! Docker Machine v0.5.0 has been just released.
And now everyone can use the official Parallels Driver for Docker Machine
🎉

P.s.
@ruimarinho By the way, there is --parallels-no-share flag implemented, so you can disable the /Users directory sharing.

Congratulations @legal90. I know this was a long and frustrating haul for you. Thanks for persevering. 👍

👍 👍 👍

Now go forth and write / use plugins everyone!!!! :D

@legal90 tears of happiness and relief are pouring on the table when I see docker running on top of your driver. I'm happier than a child who found Santa in his living room. VirtualBox has been an epic pain in the ass for the past year. Cheers to you making this go away. 🍻